前言

規格驅動開發實際上要怎麼做？Spec Kit 給了一套完整的流程與十個 Agentic Commands——今天先介紹 Spec Kit 到底是什麼。

昨天說到

昨天處理完模型與 effort，Claude Code 這邊的設定大致就位了。

工具準備好，但我們還是不知道要怎麼告訴 AI 做出一個系統。

直接丟一句「幫我做登入」給 Claude，它能夠自己寫出一個完整的功能，但過程中它替你決定了幾十件事：session 多久過期、鎖定算帳號還是算 IP、密碼怎麼雜湊，而這些決定沒有被記在任何地方，最後回頭看，只剩下程式碼，看不到當初為什麼這樣選。

我想要的是一條固定的流程：先把「要做什麼」講清楚、確認過，再讓它動手。問題是每一步該問它什麼、產出該長什麼樣，每次都得重新想一遍，因此有了Spec Kit。

Spec Kit 是什麼

GitHub 開源的 Spec-Driven Development 工具包（github/spec-kit），Spec Kit 的核心價值是把 SDD 流程、Prompt/Skill、Templates、Scripts 和 Workflow 組織起來，讓 AI Coding Agent 按照一套可重複的流程工作。

它把開發重心從「直接讓 AI 寫程式」，往「先建立規格、再規劃、拆任務，最後實作」移動。這也是我這個系列前面一直在談的 AI-Native Development：問題不是 AI 能不能寫，而是我們能不能讓 AI 在一套可追蹤、可驗證的開發流程裡工作。

安裝 Spec Kit

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

vX.Y.Z 要換成最新的 release tag，前面的 v 要留著：

(Invoke-RestMethod https://api.github.com/repos/github/spec-kit/releases/latest).tag_name

我實測的是 v1.0.4。初始化：

specify init <專案名> --integration claude

Spec Kit 裝了什麼

初始化時會建立一套標準的目錄與模板；實際內容則會依使用的 Agent、版本、preset、extension 與專案需求而不同。

十個指令

我先把十個指令分成兩組，主線四個指令：

支線六個指令：

最後一個值得留意——它處理的是規格與程式碼已經對不上的情況，也就是大部分真實專案的狀態。

先寫憲法

/speckit-constitution 產出 .specify/memory/constitution.md，是後續流程評估與產出的治理原則，相關 Skill 會把它納入後續工作。

## Core Principles
### I.   API 欄位一律 snake_case
### II.  時間一律 UTC + ISO 8601
### III. 自建認證（NON-NEGOTIABLE）
### IV.  資料庫寫入必須有測試（NON-NEGOTIABLE）
### V.   資料存取只走 ORM

這幾條是我刻意挑選的「高辨識度規則」：如果 Claude 真的有把 constitution 納入後續推理，這些規則應該會出現在後面的 spec、plan 或技術選擇裡。

實測

憲法寫好後，我丟給 Spec Kit 的需求其實非常短：

使用者用 email 與密碼登入，登入成功後取得一組 session，可以登出。
密碼連續輸入錯誤三次要鎖定帳號十五分鐘。

Spec Kit 沒有直接叫 Claude 開始寫 Code，它先把這句話轉成一組可以逐份 Review 的文件。這次實測產出的文件如下：

spec.md                   201 行   User Story、功能需求、驗收條件、Assumptions
plan.md                   254 行   技術棧、分層、實作順序
research.md               295 行   技術選型的比較與理由
data-model.md             168 行   表、欄位、關聯
contracts/openapi.yaml    149 行   API 契約
quickstart.md             206 行   怎麼把它跑起來
checklists/requirements.md 70 行   規格自檢清單
                         1343 行

它不是把：一句話 → Code，而是把：一句話 → 一組可以被人閱讀、討論、修改、追蹤的開發決策。

Spec Kit 的好處

一、流程被固定下來
不用每次自己想「這一步該問它什麼」。核心指令提供了一條可以重複執行的開發路徑，而 clarify、checklist、analyze 等指令可以插在適當的位置作為品質檢查。

二、每一步的產出都是檔案
可以 review、可以進 git、可以 diff。

三、步驟之間有審核關卡。
.specify/workflows/speckit/workflow.yml 把四個主線指令串起來，且中間插了 gate：

  - id: review-spec
    type: gate
    message: "Review the generated spec before planning."
    options: [approve, reject]
    on_reject: abort

規格沒過就不會進到 plan。

四、憲法是跨步驟的約束。
它不是某一次對話裡的提示詞，是每個階段產出前都會被讀一次的檔案。

小結

• Spec Kit 是一套寫給 AI Coding Agent 執行的開發 SOP。
• 它把自己寫成 .claude/skills/ 底下的十個 skill——跟之後要自己寫的 skill 是同一個機制，沒有自己的執行引擎。
• 它給你的是一條固定的流程（規格 → 計畫 → 任務 → 實作）和一疊可以逐份 review 的檔案，不是更快的程式碼。
• 憲法要挑跟預設行為相反的條款來寫，不然驗不出規格到底有沒有被讀進去。

明天：憲法寫好了，探針也埋好了。接下來讓 Claude 從一句話長出一份完整規格。